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ABSTRACT 



The modem tactical commander has a flood of sensory and intelligence information 
at his disposal. A tool is required to sort the information that is most pertinent to the 
decisions he must make at that time. The Command and Control Workstation of the 
Future (CCWF) is an interactive, near real-time system that displays multiple win- 
dows providing visualization of the terrain in both two and three dimensions. The ter- 
rain is drawn with Defense Mapping Agency Digital Terrain Elevation Data using 
three image resolutions in order to display large areas of terrain. This study consists 
of enhancements to prior work on the CCWF. The focus of this effort is in two areas. 
One is enhancing the maintainability of the CCWF system through use of standard 
software engineering techniques (i.e., modularization, descriptive labeling, etc.). The 
second focus is on improving the user interface of the CCWF. 
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I. OVERVIEW 



A. THE COMMAND AND CONTROL WORKSTATION 

In today’s world of supersonic missiles and aircraft, the professional naval offi- 
cer must be able to assess all sensor inputs in a matter of seconds (not minutes)! 
Expedient, correct, action is a must. To analyze multiple inputs (NTDS, radar, 
sonar), in an efficient manner, an integrated method of information presentation must 
be devised. One way to study the presentation of such information is through the 
paradigm of the command and control workstation. For that study, we propose a tool 
that collects and displays inputs from sensors in a manageable form. That tool is 
called the Command and Control Workstation of the Future (CCWF) [Ref. 1]. 

This study includes enhancements to the design and implementation of an inte- 
grated presentation method that improves the warfighting capability of today’s profes- 
sional naval officer. The CCWF’s goal is to provide a prototype visualization tool 
that is to be used in the Combat Information Center (CIC) to assist in "fighting the 
ship." The CCWF is also planned as a training tool for a CIC watch team. Additional 
goals of the CCWF include a user-friendly interface and near real-time, three-dimen- 
sional display. The CCWF is implemented on inexpensive workstations available in 
the Graphics and Video Laboratory of the Department of Computer Science at the 
Naval Postgraduate School. 
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1. Discussion 



The main advantage of using low cost (less than $100,000) workstations is 
the future capability of producing a large number of CCWFs for distribution throughout 
the Navy. At this cost, every ship will be able to integrate the CCWF into its CIC. 
When this is done, real sensor inputs will be used and the CCWF will begin to show 
its true potential. 

a. Use of Color 

The use of color in two and three-dimensional images significantly 
improves not only the appearance but the effectiveness of the display. The Watch 
Officer who must monitor several different inputs, including sensor data, communica- 
tions, message traffic, intelligence information, and ship’s location data, needs to be 
able to analyze a given display quickly. Using a color display assists in quick and 
accurate information analysis by the Watch Officer. 

b. Changing Viewpoint 

One of the Surface Warfare Officer’s main restrictions while aboard ship 
is visibility. The lack of extended visibility negatively impacts the ship-bound officer 
whenever he is on watch. While standing watch in CIC, the officer has to rely on sen- 
sors, radar and sonar to form an artificial, interpreted view. As Officer of the Deck 
(OOD) on the bridge, visibility is limited to about twelve miles on a Destroyer. Visi- 
bility can be even less when foul weather is encountered. The OOD is assisted by 
the same radar that is present in CIC, but frequently this radar is inactive in order to 
decrease the probability of being located by an enemy warship. If these sensor inputs 
are removed, CIC is completely without a view and the OOD is limited to the current 
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visibility. A strategy currently in use to minimize this limited visibility problem is the 
use of aircraft. To simulate an aircraft, or as a substitute for an aircraft, the CCWF 
allows the user to change his cunrent viewing position (viewpoint). A new viewpoint 
can be selected by the user at any time. Once selected, a three-dimensional image of 
the new viewpoint is presented, as if the user were really there. The capabilities of 
this feature include over-the-horizon (OTH) targeting, piloting through limited visibil- 
ity, or recreating the view from another platform in the battlegroup. 

c. Use of Windows 

A primary goal of the CCWF is to provide as much information as possi- 
ble in an integrated fashion. The best method of accomplishing this goal is through 
the effective use of windows. Windows are separate displays combined onto a single 
monitor. Each window contains a different type of information. The "big picture" is 
generated by combining all the data displayed in each window. 

The CCWF includes windows that display the following information: 
three-dimensional visualization from the current platform; two-dimensional display 
of the entire area, similar to a color-coded (by elevation) chart; simulator perfor- 
mance data — number of polygons drawn; position data -- latitude and longitude; 
dial and button help — includes course, speed, altitude, and other pertinent informa- 
tion about the current platform from which the viewpoint is determined. Another 
important characteristic of a window is its ability to be moved and/or resized. In the 
CCWF the two-dimensional chart window can be moved around and/or resized to 
better fit the needs of the operator. 
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d. Use of Popup Menus 



A secondary goal of the CCWF is to provide a user-friendly environ- 
ment. The importance of this objective is usually underestimated in software system 
development. The lack of proper human factors engineering is usually due to cost-cut- 
ting efforts or inadequate time spent developing the system. This can turn a good 
system into a failure when implemented if the user rejects it due to an unsatisfactory 
user-interface. 



A technique used to increase the ease with which a user masters a giv- 
en tool is the use of popup menus. A completely menu-driven interface is easier to 
master mainly because there is nothing a user has to remember. By pressing a 
mouse button a menu appears which states available options at any given time. The 
user selects an option by highlighting his choices and releasing the mouse button. 

B. SCOPE OF THIS STUDY 

The scope of this effort is to enhance previous work on the CCWF. The focus of 
these enhancements is in two main areas. First, to significantly improve the main- 
tainability of the system through application of standard software engineering tech- 
niques. These techniques include increased use of modularity, comments, and 
descriptive labeling of variables and modules. Second, provide for a friendlier user- 
interface which is not only easier to use, but provides more comprehensive informa- 
tion to the user. The goal of this system is to improve upon already existing data 
structures and algorithms in order to provide a more realistic display of sensor infor- 
mation and the sea/land environment. 
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II. FOCUS 



A. PRELIMINARY RESEARCH 

One computer graphics research project at the Naval Postgraduate School laid 
the groundwork for the current CCWF [Ref. 1]. This project concentrated on generat- 
ing a three-dimensional image of a sea/land environment that could be traversed in 
near real-time. To draw three-dimensional land images, Harris used Digital Terrain 
Elevation Data (DTED) from the Defense Mapping Agency (DMA). In order to 
decrease the number of polygons being drawn in each frame, three different levels of 
resolution were used. In the foreground, polygons are drawn using data points at 100 
yard intervals. In the mid-ground, data points are 1200 yards apart and in the back- 
ground data points are 12,000 yards apart [Ref. 1: pp 49-51]. Using three levels of 
resolution significantly increases the rate at which images can be generated. This in- 
creased image generation rate provides for more realistic animation of movement. 

B. SYSTEM MAINTAINABILITY 

One of the largest expenses of a software system over the long term is soft- 
ware maintenance. This maintenance includes correcting "bugs” that occur as the 
system is used over time. Also included in maintenance cost are system upgrades. 
These corrections and/or upgrades can be even more cosdy if the original system 
implementation team is no longer available to assist. 

Before corrections and/or upgrades to the system can be made, the current 
implementation team must spend many hours studying the existing system. After a 
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lengthy, and therefore costly, study phase the current team must determine if the 
desired system changes are feasible. Once determined feasible, the correction and/or 
upgrades may be implemented. 

During the implementation phase, additional time must be spent rewriting the 
original system. This rewriting must be done in strict accordance with standard soft- 
ware engineering principles to ensure that when future system corrections and/or 
changes need to be made, the time spent studying the system is minimized. 

Standard software engineering principles include emphasis on modularization, 
self-documenting code (numerous comments), and descriptive labeling of modules, 
variables, and constants. These principles are no more difficult to apply during the ini- 
tial system coding than during the second or third system revision . 

C. USER INTERFACE 

It is important throughout the design and implementation of any system that the 
needs of the ultimate user are considered. If the user’s needs are ignored, no matter 
how revolutionary a new system is, it may ultimately fail due to rejection by the user. 

To properly design a new system in accordance with user’s needs, complete 
analysis must be done. This analysis would include learning how the current system 
operates, defining user requirements, and evaluating alternative solutions [Ref. 2: pp 
142-151]. Once proper systems analysis is completed, design and implementation 
may begin. 

During system design and implementation, the underlying theme must be that 
the system is for the user. Keeping this in mind will ultimately lead to the delivery of 
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a system that will be well-received by the user. With the user’s acceptance the long- 
term success of the system is much more likely to occur. 

D. SUMMATION 

This study takes existing groundwork on the CCWF and adds several enhance- 
ments. These enhancements include significant improvement to the maintainability of 
the software system and an even friendlier user-interface. Improving system main- 
tainability is a particularly important focus for any project that has future potential for 
growth. Because of this importance, the use of proper software engineering principles 
should be emphasized. 
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III. IMPROVEMENT OF SYSTEM MAINTAINABILITY 



A. SYSTEM ANALYSIS 

1. Preliminary Study 

Before any work begins on an existing software system, time must be spent 
becoming familiar with the current system. The amount of time this familiarization 
process takes is dependent upon how well prior design and implementation teams 
applied the elements of good programming style. Elements of good programming 
style include: writing clearly, making programs read from top to bottom, choosing a 

data representation that makes the program simple, use of modularization, making 
every comment count, and using variable names that mean something [Ref. 3]. 

After a preliminary familiarization period has taken place, the feasibility of 
upgrading the current system must be determined. If the system is completely lack- 
ing the elements of good programming style, the current implementation team could 
decide to start from scratch. On the other hand, if the current system does make use 
of the elements of good programming style, it will be considered feasible to upgrade 
the current system. If the current system is usable, a significant amount of implemen- 
tation time will be saved. 

2. In-depth Study 

Once feasibility is determined, the current design and implementation team 
must perform an in-depth study of the existing system. Objectives considered during 
this detailed study include: determine who the system is being designed for, analyze 



- 8 - 



any limitations or constraints the project has, identify what functions the current sys- 
tem provides and to what extent these functions relate to the overall system goals, 
and learn how the current system operates. After the in-depth study has been com- 
pleted, a problem statement is generated [Ref. 2: pp 182-190]. 

3. Problem Statement 



The problem statement used for enhancing the CCWF is as follows: 



(1) Significantly increase use of the elements of good programming style. 

(2) Add lighting — compute the normal vectors for all polygons. 

(3) Convert preprocessed DMA data file to be on-line with the display program 
(no file or data duplication). 

(4) Improve user-interface through use of multiple windows. 

(5) Improve control interface — currently too sensitive. 

(6) Draw the ocean as polygons instead of an underlying plane. 

(7) Integrate ship hulls and bottoms (underwater view) into three-dimensional 
image. 

(8) Provide for changing of user’s viewpoint. 

4. Defining User Requirements 

Once the current system is completely understood, taking the time to deter- 
mine what the intended user wants the system to do is critical. If this system analy- 
sis step is not performed, an otherwise effective system could fail because it doesn’t 
do what the user wants. 



The objectives of the user requirements study include: identifying all users 

of the new system, defining the functions that must be provided by the new system, 
ensuring that the user’s needs are in accordance with the overall goals of the system, 
and defining the data and other information that must be processed. After the user 
requirements study is completed, a requirements statement is generated [Ref. 2: pp 
191-197]. 
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5. Requirements Statement 



The requirements statement used in the CCWF is constantly expanding as 
more system features become possible. The following is a current list of system 
requirements: 



(1) Generate a three-dimensional image using DMA data. 

(2) Traverse over three-dimensional image using near real-rime animation. 

(3) Allow user to define traversal view changes with course, speed, and altitude 
inputs. 

(4) Maintain and display current position in terms of latitude and longitude 

(5) Provide system performance data using the number of polygons being drawn 
as a unit of measure. 

(6) Make use of multiple windows to present as much information as possible. 

(7) Provide a friendly user-interface with which a new user can become proficient 
in a short period of time. 

(8) Provide a User’s Manual to assist the new user in learning the system. 

(9) Generate a two-dimensional image of entire area of database. 

(10) Display user’s current position in two-dimensional image. 

(1 1) Update user’s position as it changes through application of course and speed. 

(12) Allow user to change viewpoint to another position within the database. 

(13) Allow user to return to original viewpoint. 

(14) Allow user to choose which type of platform to operate (ship or aircraft). 

(15) Allow user to select from a range of visibilities. 

B. PROGRAM STRUCTURE 



1. Top-Down Design 

After system analysis is completed the project enhancements are complete- 
ly understood. With the problem statement and requirements statement in hand, 
design of enhancements may begin. 

Through the use of top-down design methodology, each enhancement to the 
CCWF is implemented. After a specific enhancement has been selected as our 
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objective, the first step is to write a high-level pseudo-code statement describing the 
objective. We then begin refining the high-level statement into stages which when 
accomplished will meet our objective. We continue refining and filling in specific 
tasks, within each stage, until a final pseudo-code version is generated. 

To implement the modules required to meet our objective, first make use of 
the pseudo-code to review and debug the algorithm. Once the algorithm is correct, 
rewrite it using C. C is the programming language used by the Silicon Graphics IRIS 
graphics workstations. 

Another important step in top-down design is choosing a data structure. 
Throughout the design process of enhancements to the CCWF, data structures have 
been chosen that will make the program as simple as possible. The main reason for 
this being the ease with which future students will be able to familiarize themselves 
with the current system. Figure 3.1 demonstrates the use of top-down design in the 
CCWF project. 

2. Modularity 

Due to the large size of many programs’, it is basically impossible to understand how 
they function as a whole. The program must be separated into many small pieces, 
which can be implemented individually. These small pieces become the building 
blocks, or "modules" of large programs. Every module is to be designed to do one 
thing well. If a module is designed to do too many things, its usefulness will be limit- 
ed. The over-tasked module will be more complex and harder to maintain [Ref. 3: pp 
59-64]. A positive side-effect of problem simplification through modularization is 
increased program efficiency [Ref. 4: pg 105]. 
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Figure 3.1 Top-down Module Design 



Objective : Generate a two-dimensional image of entire area of database 
High-level psuedo-code : Draw two-dimensional image 



First Refinement: 



Read in data 
Draw image 
Display image 



Second Refinement: Read data into data structure 

Calculate altitude breakpoints 
Generate image relative to altitude 
Display image 



Final Refinement: Read data into array 

Calculate altitude breakpoints 

Select which window to display image 

Establish world coordinates of window 

Draw ocean as background 

Use breakpoints to establish altitude contours 

Color in points relative to altitude contour 

Display image 



The final refinement is implemented using four separate modules: 



Read data into array 


=> 


read_terrain_data 


Calculate altitude breakpoints 


=> 


calc -breakpoints 


Select which window to display image 


=> 


setwindow 


Establish world coordinates of window 


=> 


draw J2D _terrain 


Draw ocean as background 


=> 


dr aw _2D -terrain 


Use breakpoints to establish altitude contours 


=> 


draw _2D -terrain 


Color in points relative to altitude contour 


=> 


draw _2D -terrain 


Display image 


=> 


draw _2D -terrain 
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Each module can be written and compiled separately from the rest of the pro- 
gram. After the module is tested and found to perform its function in accordance with 
the system requirements, it is linked to the rest of the modules. This linking process 
integrates the newly generated module into the main program and adds the newly cre- 
ated feature to the system. 

An underlying objective of many computer programs is to automate the 
repetitiveness of an action performed by a user. When modeling the user action in the 
form of a function, the repetitiveness will remain in the form of code. Modularization 
allows for the removal of the repeated code section by separating it into an individual 
module. If any irregularities do exist in the repeated action, they can be summarized 
in the module’s argument list. 

In order to improve system maintainability, a good rule of thumb is to mini- 
mize coupling of modules. Coupling is the existence of relationships between mod- 
ules. Minimizing coupling provides for the maximum independence between 
modules. If coupling does exist, it should be made as explicit as possible [Ref. 3: pg 
62]. Explicit coupling is demonstrated in the relationship between the modules, 
setwindow() and billboard(). The only relationship between the two modules is the 
window number setwindow() needs to perform its function. This relationship is 
explicitly stated in the argument list of the module call statement. The call statement 
used by billboard() is "setwindow(BILLBOARDWIN)," where BILLBOARDWIN is 
a manifest constant equal to the billboard’s window number. 

In addition to performing only a single function, each module is to hide its 
own method of operation from the rest of the program. This principle of information 
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hiding will improve the system maintainability by allowing the individual module to be 
changed independendy of others. 

The software tool used by the CCWF to implement modularization and link- 
ing is Make. Make, an Unix operating system software tool, takes a programmer 
generated Makefile as input. The Makefile is a listing of all the modules contained in 
the CCWF (see Figure 3.2). Make, checks the time stamp on all the listed modules. 
Any module that has been modified since Make was last executed is recompiled. 
Once all modules are compiled, Make automatically links the entire list of modules. 
Output from Make is a single executable program. 

C. DOCUMENTATION 

1. Importance 

The significance of complete documentation to the future maintainability of a 
software system cannot be understated. Without accurate and comprehensive docu- 
mentation, upgrading a system is infeasible. Such a large amount of time will be 
spent learning the current system, the costs of enhancements will far outweigh any 
benefits gained. Because of the excessive familiarization costs, the enhancement 
design and implementation team will be better off to start from scratch. 

2. Documentation Techniques 

The primary technique used by the CCWF is that of self-documenting code. 
Self-documentation is accomplished through the application of several different princi- 
ples. First, the program is written with a clean structure. A well structured program 
follows from the use of a top-down design methodology. The program is read from 
top-to-bottom as the system actually works. When this is true the familiarization 
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Figure 3.2 CCWF Makefile 



CFLAGS = -Zg -g 
OBJS = 3d.o\ 

adjust_bounds.o\ 

billboard. o\ 

calc_breakpoints.o\ 

clear_overlays.o\ 

colorramp.oX 

do_menu.o\ 

draw_2 D_terrain ,o\ 

draw_cell.o\ 

draw_dials.o\ 

draw_ocean.o\ 

draw_poly.o\ 

draw_skirt.o\ 

draw_terrain.o\ 

gamma.oX 

get_terrain.o\ 

init_controls.o\ 

init_graphics.o\ 

init_queue.o\ 

init_terrain.o\ 

init_view.o\ 

inirialize_3d.o\ 

mainmenu.oX 

make_levell.o\ 

make_level2.o\ 

make_level3.o\ 

maxmin.oX 

name_conv.o\ 

open_2D_terrain_wind.o\ 

open_3D_terrain_wind.o\ 

open_billboard_wind.o\ 

open_dial_help_wind.o\ 

open_performance_wind.o\ 

open_posit_wind.o\ 

open_windows.o\ 

platform_crashed.o\ 

process_DIALO.o\ 

process_DIAL4.o\ 

process_DIAL5.o\ 
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Figure 3.2 CCWF Makefile (continued) 



process_view_select.o\ 

read_terrain_data.o\ 

relocate_mouse.o\ 

setwindow.oX 

timer.oX 

update_2D_position.o\ 

update_diaI_data.o\ 

update_elevation.o\ 

update_performance_data.o\ 

update_posit.o\ 

update_position.o 

HDRS 1 = get_terrain.o read_terrain_data.o 

HDRS2 = adjust_bounds.o\ 
draw_cell.o\ 
draw_ocean.o\ 
draw_poly.o\ 
draw_terrain.o\ 
process_view_select.o 

HDRS3 = 3d.o\ 

billboard.oX 

calc_breakpoints.o\ 

clear_overlays.o\ 

colorramp.oX 

do_menu.o\ 

draw_2D_terrain.o\ 

draw_dials.o\ 

draw_ocean.o\ 

draw_skirt.o\ 

gamma.oX 

get_terrain.o\ 

init_controls.o\ 

init_graphics.o\ 

init_view.o\ 

open_2D_terrain_wind.o\ 

open_3D_terrain_wind.o\ 

open_billboard_wind.o\ 

open_dial_help_wind.o\ 

open_performance_wind.o\ 

open_posit_wind.o\ 



- 16 - 



Figure 3.2 CCWF Makefile (continued) 



platform_crashed.o\ 

process_DIALO.o\ 

process_DIAL4.o\ 

process_DIAL5.o\ 

read_terrain_data.o\ 

relocate_mouse.o\ 

setwindow.oX 

update_2D_position.o\ 

update_dial_data.o\ 

update_elevation.o\ 

update_performance_data.o\ 

update_posit.o\ 

update_posi tion.o 

HDRS4 = 3d.o\ 

do_menu.o\ 

draw_2D_terrain.o\ 

get_terrain.o\ 

init_terrain.o\ 

init_view.o\ 

mainmenu.oX 

make_levell.o\ 

make_level2.o\ 

make_level3.o\ 

process_DIALO.o\ 

process_DIAL4.o\ 

read_terrai n_data.o\ 

relocate_mouse.o\ 

update_2D_position.o\ 

update_diaI_data.o\ 

update_posit.o\ 

update_position.o 



3d : $(OBJS) 

cc -o 3d $(OBJS) $(CFLAGS) 



$(HDRS1): filenames.h 
$(HDRS2): terrain.h 
$(HDRS3): constants.h 
$(HDRS4): typedef.h 
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process is much shorter than when no structure exists in the program (see Figure 
3.3). 



Another principle used by the CCWF to increase comprehension while 
reviewing the program is the use of code formatting. Proper use of "white space" and 
indentation makes the program’s logical structure much easier to determine. 

The best technique of documenting expressions, variables, modules, and 
constants is to use identifiers that have meaning. The C programming language pro- 
motes this technique through the use of manifest constants and unlimited length iden- 
tifiers. The CCWF has two header files, constants. h and terrain.h, which list all the 
manifest constants used throughout the system (see Figure 3.4). 

Any additional documentation needed is in the form of comments to the 
source code. Comments are included in the CCWF whenever it is anticipated that a 
future reader may have difficulty understanding what the code is doing at that point. 
Comments are not in the form of a line-by-line explanation of what is happening. 

3. Charts 

Another method of describing a program is through the use of chans. Chans 
used to provide additional documentation to the CCWF are a Structure Chan, Calls 
Hierarchy Chan, Module Purpose List, and a Module Call List. 

The CCWF Structure Chart, Appendix A, is a treelike representation. Each 
node on the tree represents a module within the CCWF. Modules are broken down 
into sub-modules in top-down design fashion. Once all the modules of the CCWF 
are represented, execution will occur in a top-to-bottom, left-to-right sequence. 
Looping is also demonstrated in the structure chart via a ring-like anow. 
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Figure 3.3 CCWF Self-documenting Code 
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Author: Rex Cobb 

Written: 09 AUG 88 

File Name: process_DIAL0.c 

Purpose: process DIALO queue entry — course change 

Parameters: structure view (type viewpoint), input course change, 

and lock on status 

Returns: updated structure view (myview in 3d.c) 









/*#define DPRINT 1 */ /* debug print statements */ 
process_DIAL0 (view,icrs,lock_on) 

viewpoint *view; /* data structure 3D image is calculated relative to */ 
short icrs; /* intended course */ 

Boolean lock_on; /* true when look direction is locked onto course */ 

{ 

short course_change=0; /* change in course between dial 0 input */ 
#ifdef DPRINT 

printf("process_DIALO %d\n"); 
printf("icrs = %d\n",icrs); 

#endif DPRINT 



if (icrs < 0) 

{ 

icrs = icrs + DEGREES_IN_COMPASS; 

) 

else if (icrs > DEGREES_IN_COMPASS) 

{ 

icrs = icrs - DEGREES_IN_COMPASS; 

} 

course_change = icrs - (short)(view->crs); 
view->crs = (float)(icrs); 
if (lock_on) 

view->lookdir = view->lookdir + (float)(course_change); 

) 



- 19 - 



Figure 3.4 CCWF Use of Manifest Constants 
(excerpt from constants.h) 



/* window id numbers */ 



#define BILLBOARD WIN 0 
#define POSITWIN 1 
#define DIALHELPWIN 2 
#define TERRAINWIN 3 
#define TWODTERRAINWIN 4 
#define PERFORMWIN 5 



/* constants for 3d display */ 



#define LATITUDE 31 
#define LONGITUDE 131 
#define MINELEVATION 0 
#define MAXELEVATION 1120 
#define DEGREES_IN_COMPASS 360 
#define INITIAL_HEADING 4 
#define INITIAL_SPEED 0 
#define INITIAL_ALTITUDE 35 
#define INITIAL_LOOK_ANGLE 0 
#define INITIAL_LOOK_DISTANCE 0 
#define MAX_NUMB_COURSE_TURNS 
#define MAX_AIRCRAFT_SPEED 1000 
#define MAX_SHIP_SPEED 35 
#define MAX_ ALTITUDE 5000 
#define MAX_LOOK_ANGLE 150 
#define MIN_ ALTITUDE -100 
#define MIN_LOOK_ANGLE 0 
#define MAX_LOOK_DISTANCE 240 
#define DIALTOYARDS 10 
#define WINDOWYARDS 100 



/* subject cell */ 

/* subject cell */ 

/* lowest elevation in 2D map */ 

/* highest elevation in 2D map(meters)*/ 

/* degrees */ 

/* knots */ 

/* yards */ 

/* degrees */ 

/* yards */ 

2 

/* knots */ 

/* knots */ 

/* yards */ 

/* degrees */ 

/* degrees */ 

/* number of miles in cell*4 */ 

/* conversion for dial input to yards */ 

/* multiplier used to properly update dial 
showing distance of look direction */ 



/* dial sensitivity constants, used to improve smoothness of dial input */ 



#define ALTSENS 6 /* altitude DIAL2 */ 

#define COURSESENS 10 /* course DIAL0 */ 

#define AIRCRAFT_SPEEDSENS 10 /* speed DIAL1 for aircraft */ 

#define SHIP_SPEEDSENS 20 /* for ship */ 

#define LOOKANGSENS 20 /* look angle DIAL5 */ 
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The purpose of the Calls Hierarchy Chart, Appendix B, is to display calls to 
and by each function within the CCWF. 

The List of CCWF Modules and their Purpose, Appendix C, describes every 
module in the CCWF and what function it performs. 

The List of CCWF Modules and Who they are called by, Appendix D, 
describes every module in the CCWF and what module(s) it is called from. 

All charts for the CCWF have been designed to improve the maintainability 
of the software system. Although charts do improve system maintainability, they are 
of only secondary importance since a programmer can only know for sure what the 
program does by reading the code itself. Program documentation in this format will 
significantly decrease the time required for future students to familiarize themselves 
with the CCWF system. The ease with which the software system can be learned 
will further promote the number of enhancements that can be implemented in a given 
amount of time. 

4. User’s Manual 

During the delivery of a software system, an important piece of documenta- 
tion for the ultimate user is the User’s Manual, Appendix E. The CCWF User’s 
Manual is written in the form of a stand-alone document which describes all the sys- 
tem features and how to make use of them. The user is assumed to have no prior 
knowledge of how to operate either the CCWF or a mouse-driven interface. 
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D. CONCLUSIONS 



To ensure the maintainability of the CCWF, several important principles of soft- 
ware engineering have been followed. 

These principles include spending sufficient time studying the project to 
determine its feasibility. Once the project is determined feasible, additional time 
must be spent performing an in-depth study. The in-depth study will result in a 
complete understanding of the problems needing to be solved. Prior to beginning 
system design, the user’s requirements must be defined. If the ultimate user’s needs 
aren’t defined, an otherwise excellent system could be doomed to failure due to user 
rejection. 

Once a complete system analysis is completed, the design process may begin. 
During design, emphasis is placed on a top-down structure with an effective use of 
modularity. Because of this design emphasis, maintainability is significantly 
increased due to the ease with which future enhancement teams will be able to famil- 
iarize themselves with the CCWF. 

During analysis, design, and implementation of the enhancements to the 
CCWF, documentation plays an important part. Documentation takes on several 
forms in the CCWF. Primarily the code is intended to be self-documenting through 
the use of clean, well- structured modules. By using regular formatting and identifiers 
(variables, constants, module names) that have meaning, familiarization time is 
greatly reduced. Other documentation used to assist future enhancement teams 
includes comments and charts. Structure charts and hierarchical charts assist famil- 
iarization by showing the high-level view of what the different modules do and how 
they relate to each other. 
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Another form of documentation, designed for the ultimate user of the CCWF, is 
the User’s Manual. This document is important since the long term success of the 
CCWF is completely dependent upon acceptance by the ultimate user. The User’s 
Manual explains all the features of the CCWF and how to use them. Without this 
form of reference material, the probability of user rejection is increased. 

Through proper analysis, design, and documentation of enhancements to the 
CCWF, system maintainability is significantly improved. Future enhancements will 
be implemented with much less difficulty and in a more time-efficient manner. 
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IV. ENHANCEMENTS TO THE USER INTERFACE 



The primary objective of the command and control workstation of the future 
(CCWF) is to present multiple "chunks" of information to a user. This information 
must be presented in a fashion that can be interpreted and reacted to in a minimal 
amount of time. An effective method of displaying the information is through the use 
of multiple windows, one chunk of information for each window. 

A. USE OF MULTIPLE WINDOWS 

Whenever more than one chunk of information is being presented to a user, the 
chunks are to be divided up into separate entities. A rule of thumb followed during 
the design of the CCWF is to avoid presenting more than five to nine chunks to a user 
at any one time [Ref. 4: pg 62]. The CCWF uses five separate windows to provide 
the user with the ability to analyze the available sensor information as needed. Fig- 
ure 4.1 shows the relational layout of the CCWF display. Each window displays a 
different type of information to the user. 

1. Three-Dimensional Terrain Window 

The Three-Dimensional Terrain Window displays a visualization of surroun- 
ding terrain calculated relative to the user’s position. To generate this view, the 
CCWF accesses a preprocessed database of Digital Terrain Elevation Data (DTED) 
provided by the Defense Mapping Agency (DMA) [Ref. 1: pp 35-42]. 
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Figure 4.1 CCWF Window Layout 



The DTED, used in the CCWF, describes a 60 mile square (cell), whose 

o o 

bottom left corner is located at 31 North Latitude, 131 East Longitude. The subject 
cell includes parts of one of Japan’s southern islands and the Sea of Japan. This spe- 
cific cell was selected due to its interesting combination of land, islands, and water. 

The DTED consists of a series of data points occurring at approximately 100 
yard intervals throughout the cell. This equates to a data array of 1,200 by 1,200, or 
1.44 million data points for each cell. Since each data point is represented in the form 
of a 16 bit integer, the memory storage required for each cell is 2.88 megabytes. 
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a. Techniques Used to Draw the Image 



Due to the large number of data points used to describe a single cell, 
the CCWF uses two independent techniques to speed up the generation of the three- 
dimensional image. First, the initial 1,200 by 1,200 array of data points is prepro- 
cessed. The preprocessing is performed prior to running the CCWF and results in a 
new, compressed, data structure of less than one megabyte in size [Ref. 1: pp 53- 
61]. This compressed data structure is more efficient and therefore allows the CCWF 
to generate three-dimensional images more quickly than when using the original 
array. 



A second technique used is drawing the terrain in three different levels 
of resolution. Displaying the terrain in this fashion models the way the viewer actual- 
ly sees. Objects that are close to the viewer are seen with a high level of detail. As 
objects get further away, the level of detail decreases accordingly. Objects that are 
far off in the distance are seen with little detail, if they are seen at all. 

Each level of resolution is determined relative to the distance of the ter- 
rain from the viewer. In the foreground, nearest the viewer, polygons are drawn with 
vertices at 100 yard intervals. This is the highest resolution possible since every 
available data point is being used. The terrain located in the image’s middle-ground 
uses data points at 1,200 yard intervals to form polygons. The background is drawn 
with vertices at 12,000 yard intervals. Generating the three-dimensional terrain 
using three levels of resolution reduces the number of polygons being drawn from 
greater than 100,000 to approximately 10,000. This factor of ten decrease in the num- 
ber of polygons being drawn significantly increases the speed with which the three- 
dimensional image is generated [Ref. 1: pp 49-52]. 
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b. Coloring Terrain by Elevation 



To provide a more realistic image to the viewer, the terrain is color-cod- 
ed relative to elevation. To do this, during initialization of the CCWF, 
calc_breakpoints(), generates an array of 16 breakpoints evenly distributed between 
the cell’s minimum and maximum elevation. Prior to the drawing of a terrain polygon, 
make _polly(), compares the y coordinate (elevation) of one vertex of the polygon to 
the array of breakpoints. From this comparison the current color is established and 
used in the following polygon fill operation. The resulting image uses green shades in 
lower elevations, yellow shades at medium elevations, and shades of red for higher 
elevations. 

2. Dial and Button Help Window 

The Dial and Button Help Window, (see Figure 4.2), performs a dual func- 
tion. First, this window provides the user with a description of the dial and button 
box functions. Second, current platform status information is displayed. 

a. Help Function 

The Dial and Button Help Window is a form of "on-line help" provided 
to the user. On-line help will increase the ease with which the user is able to famil- 
iarize himself with the CCWF system. Due to this ease of familiarization, the proba- 
bility of long-term user acceptance is increased. 

Help is provided in the form of functional descriptions below a drawing 
of each dial. The descriptions identify what effect manipulation of each dial will have 
on the user’s platform. Also displayed is the unit of measure for each dial’s function. 
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Figure 4.2 Dial and Button Help Window 
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Help is also provided for the use of the Button box. Each active but- 
ton’s location is described along with the effect each has on the displays. 

b. Platform Status Function 

The second role of the Dial and Button Help Window is to provide con- 
tinuously updated status information. The status information, relative to the viewer’s 
current platform, includes: course, speed, altitude, look direction, look distance, and 
altitude above ground. 

The platform’s course is displayed in degrees from true north. Speed is 
in knots (nautical miles per hour) and is limited to less than or equal to 35 for a ship. 
The maximum speed allowed for an aircraft is 1,000 knots. Altitude, actually the 
height of the viewer’s eye, is displayed in yards above sea level. The altitude for a 
ship is set to a constant ten, since the bridge of many ships is approximately 30 feet 
above the water. The maximum altitude for an aircraft is 5,000 yards. Look direction 
is displayed in degrees from true North. Look direction is independent of course. 
This is demonstrated by a viewer who is on a platform traveling due North but looking 
at an object off the starboard beam. The viewer’s course is 000 °and his look direction 
is 090°. The three-dimensional terrain image is generated from the look direction. 
Look distance is displayed in yards from the viewer’s current platform. Turning the 
look distance dial changes the length of the black line in the Two-Dimensional Terrain 
Window. By manipulating both the look direction and look distance dials, the user 
can determine the range and bearing to an object. To do this, place the end of the 
black line on the object of interest and read the look direction and look distance 
displays for range and bearing data. Altitude above ground, in yards, is also 
displayed in the Dial and Button Help Window. This value is calculated by 
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subtracting the elevation at the point directly below the user’s platform from the 
altitude of the platform. If this value is less than or equal to zero, the platform will 
crash. To recover from a crash, the user must increase platform altitude until the 
elevation above ground is greater than zero. 

The dual role design of the Dial and Button Help Window provides an 
efficient, understandable method to display both help and status information. In addi- 
tion, due to the co-location of data with a graphical display, immediate feedback is 
provided to the user for every dial manipulation. 

3. Position Window 

The Position Window, (see Figure 4.3), displays the current position data 
for the user’s platform. Latitude and longitude are provided in units of degrees, min- 
utes, and seconds. Whenever the user’s platform speed is greater than zero, the lati- 
tude and longitude are updated by update _posit(). The user can plot these position 
readings on a navigational chart. After a given amount of time, the actual track of the 
user’s platform will be formed. Another, more efficient, method of locating the user’s 
platform in relation to the surrounding area, is by observing the CCWF’s Two- 
Dimensional Terrain Window. 



LATITUDE: 31 21 30.00 North 
LONGITUDE: 131 10 30.00 East 



Figure 4.3 Position Window 
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4. Two-Dimensional Terrain Window 



a. Piloting Features 

The Two-Dimensional Terrain Window displays the entire cell (60 mile 
square) to the user (see Figure 4.4). Within the window, the user’s current position 
is indicated by a small red circle. As the user’s platform moves, the red circle moves 
accordingly. This CCWF feature removes the need for constantly plotting latitude 
and longitude on a navigational chart (piloting). With this time-intensive requirement 
removed, more time can be spent analyzing other sensor data. 




Figure 4.4 Two-Dimensional Terrain Window 
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Another piloting feature provided in the Two-Dimensional Terrain Win- 
dow is a line of dead reckoning (DR). The magnitude of the red line (DR) in the Two- 
Dimensional Terrain Window is controlled by the platform’s speed. The length of the 
DR line represents how far the platform will travel in six minutes. The direction of the 
DR line is equal to the platform’s course. 

b. Use as a Radar Repeater 

By manipulating the look direction and look distance dials, the black line 
in the Two-Dimensional Terrain Window models the behavior of a bearing and range 
cursor on a radar repeater. This feature can be used to determine the bearing and 
range to another platform. It can also be used to determine bearings and ranges to a 
series of terrain points in order to generate a navigational fix. 

The two-dimensional terrain is color-coded relative to elevation. 
Because of this feature, a user is better capable of selecting prominent geographical 
features to determine bearings and ranges. This capability is particularly important 
when performing coastal navigation in a region with a low, featureless coastline. This 
type of coastline would not provide any points to navigate by using radar alone. The 
radar operator would have to use geographical features that are further inland. Posi- 
tive identification, on a navigational chart, of these inland points would be difficult. 
Therefore, the bearings and ranges taken would be of little navigational value. 

Using the CCWF Two-Dimensional Terrain Window, the operator is 
able to positively identify inland points on a chart. This identification is made possi- 
ble since the terrain is color-coded relative to elevation. By determining the point’s 
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elevation from its color, the user can compare the elevation to the chart and make a 
positive identification of the subject point. Once identified, the bearing and range to 
the point is determined and an approximate position is determined. 

c. Implementation 

The two-dimensional terrain is drawn as the CCWF is being initial- 
ized. Prior to drawing the terrain image, read_terrain_data( ) reads the DTED into a 
1,200 by 1,200 array. To draw the terrain, draw_2D_terrain(), processes the data 
array by drawing a small rectangle color-coded relative to elevation. Using every 
data point in the array (1.44 million points), generating an image takes approximately 
11 seconds. By processing every other point (720,000 points), only six seconds is 
needed to draw the image. This almost 50 percent reduction in processing results in a 
more time-efficient algorithm with minimal reduction in resolution. 

To improve the user interface, the two-dimensional terrain image is 
drawn in both buffers simultaneously. By doing this, the user actually sees the image 
form. Providing something to look at increases the friendliness of the CCWF. This is 
true because the user will be less likely to get impatient while waiting for a response. 

The course DR (red) and look direction (black) lines are drawn in the 
Two-Dimensional Terrain Window using overlay planes. The use of two overlay 
planes allows the CCWF to draw images of up to three colors on top of an already 
existing image [Ref. 5: pg 11-1], The use of overlay planes by update_2D _position(), 
allows the CCWF to make changes within the Two-Dimensional Terrain Window 
without continuously redrawing the image. 
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5. Performance Data Window 



The Performance Data Window displays the number of polygons being 
drawn in the three-dimensional terrain image. This value is calculated in draw_cell( ) 
by summing the number of calls to make _polty() and draw_skirt(). Each call repre- 
sents the drawing of one polygon. The final sum is updated for each frame and dis- 
played as seen in Figure 4.5. 



Polygons being drawn = 

5000 



Figure 4.5 Performance Data Window 
B. USE OF POP-UP MENUS 

When designing a system to have a friendly user interface, minimizing the num- 
ber of actions the user needs to remember is important. The CCWF accomplishes 
this objective through the use of a series of pop-up menus. On the IRIS 4D-70GT 
graphics workstation, there are two types of pop-up menus. The IRIS window man- 
ager, Max, provides a system pop-up menu. The IRIS GL graphics library also pro- 
vides the system developers the capability of defining system specific menus. Both 
types of IRIS menus are used by the CCWF. 
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1. Max System Menu 



The pop-up menu provided by the IRIS window manager. Max (see Figure 
4.6) is accessed by locating the cursor on any window title bar and pressing the right 
mouse button (menu button). 




Figure 4.6 Max System Menu 

The primary use of the Max system menu in the CCWF is to provide the 
user with the capability of moving and/or resizing the Two-Dimensional Terrain Win- 
dow. By enlarging the window, the user can perform more detailed operations within 
the Two-Dimensional Terrain Window. By moving the window to a more centralized 
screen location and enlarging it, the user is better able to concentrate on the two- 
dimensional view (see Figure 4.7). This capability is most important when land is 
beyond the viewer’s range of visibility. 

A secondary use for the Max system menu is allowing the user to exit the 
CCWF system. This capability is also provided by the CCWF system menu. 

2. CCWF System Menu 

The second type of pop-up menus used by the CCWF are the menus 
designed by the CCWF system developers. The main menu (see Figure 4.8) is 
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Figure 4.7 Moved and Enlarged 2-D Window 



accessed by locating the cursor in the interior of any window and pressing the menu 
button. The menus are defined in DefineMenu(). In order to support the objective of 
providing a friendly user interface, the CCWF system menus limit the number of alter- 
natives provided to the user. Sanders and McCormick [Ref. 6: pg 62] state that, "If 
more than seven alternatives are displayed on the screen, a person may tend to forget 
the first alternative before the last ones are read." To stay within the guideline of no 
more than seven alternatives, the CCWF uses a series of sub-menus. 
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Quit 





Figure 4.8 Main Menu 



3. Use of Sub-Menus 

These sub-menus are accessed by rolling the mouse cursor off the side of 
any main menu selection containing an arrow. Using this method establishes a hierar- 
chical menu structure which makes sense to the user. The user decides what type of 
function in the main menu is desired and by rolling the mouse to the side of that selec- 
tion is provided with specific actions that can be executed. In the CCWF, there are 
three sub-menus: platform select, visibility range, and change viewpoint. 

a. Platform Select 

Selection of this sub-menu allows the user to choose which type of plat- 
form is desired (see Figure 4.9). By selecting "Ship," the three-dimensional image 
generated by the CCWF is at a constant altitude of 30 feet. Maximum speed is limit- 
ed to 35 knots and the user does not have the ability to change altitude. By selecting 
"Aircraft," which is the default mode, the user has the ability to increase speed to 
1,000 knots and altitude to 5,000 yards. 
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Figure 4.9 
Platform Select 
Sub-Menu 



b. Visibility Range 

Selection of this sub-menu allows the user to set different levels of visi- 
bility (see Figure 4.10). The available choices are: Unlimited (default mode), 15 

miles, ten miles, five miles, and three miles. By selecting the lesser values, 
inclement weather can be simulated by decreasing the amount of terrain the viewer is 
capable of seeing. A positive side effect of decreasing the visibility, is speeding up 
the rate at which the CCWF is capable of generating the three-dimensional image. 



Select Visibility 
Unlimited 

15 miles 

10 miles 

5 miles 

3 miles 



Figure 4.10 Visibility Sub-Menu 



c. Change Viewpoint 



The capability to move from one viewpoint to another is provided by this 
sub-menu. When "Select new viewpoint with left mouse" is selected, the cursor 
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immediately goes to the Two-Dimensional Terrain Window. At this point, the user 
chooses a new viewpoint within the window by placing the cursor on the desired loca- 
tion. Pressing and releasing (clicking) the left mouse button at this time causes the 
CCWF to redraw the three-dimensional image as if the viewer were now located at 
the new viewpoint. 

In 2D window: 

Select new viewpoint with left mouse 
Return to original view with middle mouse 



Figure 4.11 View Change Sub-Menu 

In the Two-Dimensional Terrain Window, the original viewpoint is 
marked by a small yellow circle which continues to move in accordance with the origi- 
nal course and speed. The new viewpoint is indicated by a small red circle. The 
course DR (red) and look direction (black) lines are also provided at the new view- 
point. The user may manipulate the dials (course, speed, altitude, look direction, and 
look distance) to change the images as desired. The user may change viewpoints as 
many times as desired using the Main and Change Viewpoint menus. When ready to 
return to the original viewpoint, marked by the yellow circle, the user clicks the middle 
mouse button. 



This ability to change viewpoints can be used in several different ways 
to further improve the effectiveness of the CCWF. These uses include: performance 
of over-the-horizon targeting, looking around bad weather by changing viewpoint, and 
viewing from the perspective of another platform. 
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C. USE OF DIALS AND BUTTONS 



The IRIS button and dial boxes function as the primary user interface. The 
active buttons function as toggle switches. The dials allow the user to drive the view- 
er’s platform around the cell using dial manipulations that make sense. 

1. Button Toggles 

Two buttons have been activated for use as toggle switches in the CCWF. 
The top left button turns the ocean’s grid lines on and off. These grid lines are used 
to provide a sense of motion to the viewer who is out of sight of land [Ref. 1: pg 48]. 

The other toggle switch, bottom left button, affects the Two and Three- 
Dimensional Terrain Windows. By pressing this button, the look direction cursor 
(black line) in the Two-Dimensional Terrain Window is locked onto the course DR 
(red line). The three-dimensional image reflects this change immediately. The pur- 
pose of this feature is to allow the user, who is looking in a direction away from the 
platform’s course, to quickly view the image directly ahead of the platform. The look 
direction will remain locked onto the course direction until the toggle switch is 
pressed again. When pressed a second time, the viewer’s image will return to the 
original look direction. 

2. Dial Location vs. Function 

The assignment of a dial’s function is made considering the frequency with 
which the user will generate that type of input (see Figure 4.2). Most frequent user 
input, while driving the platform, will be course and speed changes. Because of this 
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frequency, course and speed dials are located at the bottom of the dial box. This loca- 
tion will provide the greatest ease of operation for the user. When the viewer’s plat- 
form is an aircraft, altitude is frequently changed and therefore, the altitude dial is just 
above the course dial. 

The top two dials, in Figure 4.2, are look direction and look distance. These 
dials are used either to view a specific object of interest or, when used together, 
determine the bearing and range to an object of interest. Because of their complemen- 
tary function, an effective spatial relationship is needed. To provide this relationship, 
which results in the best possible user interface for this situation, the dials are locat- 
ed next to each other. This is a common sense arrangement which eases the user’s 
familiarization process. 

D. CONCLUSIONS 

The most important part of any system could very well be the user interface. 
The CCWF is designed to provide an interface which is as friendly to the user as pos- 
sible. This friendly user interface is accomplished in several different ways. 

First, through the use of multiple windows, five different kinds of information are 
provided to the user simultaneously. The wealth of information available from the 
CCWF assists the user in more effectively performing his job. In addition to reporting 
a large quantity of information, the CCWF presents this information in a manner 
which is easily interpreted. This is demonstrated by the CCWF color-coding the ter- 
rain by elevation in both the Two and Three-Dimensional Terrain Windows. 

Second, the CCWF uses a form of on-line help to effectively reduce the amount 
of information the user must remember. On-line help is provided in both the Dial and 
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Button Help Window and through the use of pop-up menus. The information dis- 
played in the Dial and Button Help Window acts as a reminder to the user of the func- 
tionality of all active dials and buttons. Pop-up menus, when displayed using the 
menu button, remind the user of features available and provide an easy method of 
selecting a desired feature. 

Finally, by locating controls used for input (dials and buttons) in a logical, easy 
to remember position, user familiarization time will be minimized. Because of this 
minimal user familiarization time, the probability of user rejection will be reduced, and 
long term acceptance of the CCWF will be probable. 
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V. CONCLUSIONS 



A visualization tool to be used by today’s naval officer, to assist in assessing 
multiple sensor inputs, is provided by the Command and Control Workstation of the 
Future (CCWF). The CCWF prototype, currently being developed using low cost 
graphics workstations, demonstrates the need for a tool which presents numerous 
chunks of information in a manageable form. This study focuses on enhancing the 
CCWF through improved system maintainability and a friendlier user interface. 

A. SYSTEM MAINTAINABILITY 

Future enhancement teams must spend adequate time understanding the cur- 
rent CCWF system. This preliminary study is to be completed prior to beginning the 
design of any new features. Familiarization time required by future enhancement 
teams will be greatly reduced due to the efforts of this study. Once familiarization is 
achieved, feasibility of enhancing the CCWF is determined. Once determined feasi- 
ble, the problem statement and user requirements are updated. 

While designing solutions to the problems and requirements, a structured 
approach is best for future system maintainability. Through the use of a top-down 
design methodology, CCWF enhancements are implemented. 

In addition to top-down design, modularity plays a significant role in system 
maintainability. Modularization simplifies the CCWF by breaking up the program into 
small pieces. Each piece, module, is tasked with doing only one thing. 
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To assist the enhancement team during system familiarization and enhance- 
ment design, comprehensive documentation is provided. Documentation of the 
CCWF is accomplished primarily through the use of self-documenting code. Addition- 
al documentation is provided through the use of charts and a User’s Manual. Docu- 
mentation is to be constantly updated as new enhancements are implemented. 

Due to the dynamic nature of the CCWF, proper and complete analysis and 
design must be accomplished. If future enhancement teams do not invest adequate 
time in design and analysis the feasibility of further enhancements will be reduced. 

B. USER INTERFACE 

During the analysis phase of system development, the user’s requirements are 
updated. This updated requirements list provides the enhancement team with a 
series of features to be implemented to improve the user interface. 

The primary enhancement provided by this study is to improve the presentation 
method of multiple chunks of information to the user. The CCWF’s use of multiple 
windows is an ideal way to integrate numerous displays of data onto one monitor. 

Coloring terrain by elevation in both the two and three-dimensional displays 
increases the realism of the image. In addition to an increase in realism, data dis- 
played is easier to interpret due to the coding of elevation data by color. 

Another method used by the CCWF to improve the user interface is on-line 
help. This on-line help is available in two fashions. First, the Dial and Button Help 
Window provides both platform status information and functional explanations for the 
user input controls (dials and buttons). The second method the CCWF uses to pro- 
vide on-line help is through the use of pop-up menus. 
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Pop-up menus increase the ease with which the user becomes proficient with 
the CCWF. The user has less to learn because possible actions are listed in menus. 
To execute an action, the user selects the desired action through the menu. Thus, the 
effective use of menus decreases the number of procedures the user is required to 
learn. 



Development of a user interface that is as friendly as possible is a top priority 
for the CCWF. The importance of this goal, a friendly user interface, is not to be 
underestimated at any time during system development. Not emphasizing the impor- 
tance of the user interface can result in long-term project failure due to user rejection. 

C. FUTURE WORK 

Follow-on work in enhancing the CCWF will include integration of a lighting 
model. More realistic three-dimensional images can be generated using Gouraud 
shading. On the Silicon Graphics, Inc. IRIS 4D/70GT, Gouraud shading can be imple- 
mented "free" to the CCWF. 

The CCWF should be able to generate the three-dimensional image without the 
use of a preprocessed data file. Making use of the 1200 by 1200 DMA data array, 
that already exists in the CCWF, will remove the need for data duplication. 

An underwater image needs to be included within the Three-Dimensional Ter- 
rain Window. The capability of selecting a submarine as a platform could actuate an 
entirely separate set of drawing routines. The visualization provided would include 
platforms that already exist from the surface image. Integration of the surface and 
sub-surface views will add an entirely new dimension to the CCWF. 
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Other enhancements include: an NTDS type display, ability to change view- 

point to a platform selected from the NTDS display, integration of cultural features 
available from DMA data files, and the ability to display tactical information about 
selected contacts [Ref. 1: pp 74-75]. 

The list of potential features needed by the CCWF is constantly growing. To 
ensure that future enhancements are feasible, design and implementation teams must 
always strive for a high level of system maintainability. In addition, the future imple- 
mentation of all enhancements needs to provide a friendly user interface to ensure 
user acceptance and long-term CCWF success. 
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APPENDIX A - STRUCTURE CHART 
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APPENDIX B - CALLS HIERARCHY CHART 
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APPENDIX C - CCWF MODULES AND THEIR PURPOSE 



Source Code Files 



3d — main program driver contains main event loop 

adjust_bounds - updates cell boundaries prior to drawing 3D terrain view 

billboard — draws title screen while data structures are being loaded 

calc_breakpoints — calculates 16 altitude levels, used when choosing color for 2D 

and 3D views 

c!ear_overlays — clears overlay planes in all windows 
colorramp — establishes user defined color map 
DefineMenu (mainmenu.c)— defines popup menus 
do_menu -- processes different popup menu selections 
draw_2D_terrain — draws two dimensional terrain map in 2D window 
draw_cell — draws 3D image given current location and heading 
draw_dials — draws dials and specifies their uses in dial help window 
draw_ocean — draws blue ocean plane 

draw_skirt — draws underlying polygon to conceal differences in resolution 
boundaries 

draw_terrain — calculates data and calls drawing routines to draw 3D 
image 

get_terrain — read in terrain data used to draw 3D image 



- 55 - 



init_controls — initializes dials using setvaluator() and noise() 

init_graphics — configures IRIS for operation in z-buffering mode; calls 
procedure colorramp to define color map 

init_queue -- selects devices to be queued using qdevice() 

init_terrain - establishes terrain data structure 

init_view — initializes variable view, initial viewpoint when program 
started 

initialize_3d — displays billboard and calls modules required to set up 3d 
make_levell -- draws level one polygons in 3D image 
make_level2 —draws level two polygons in 3D image 
make_level3 —draws level three polygons in 3D image 

make_polly (draw_poly.c)- draws polygons in 3D cell colored relative to altitude 

maxmin — max4,min4: calculates maximum/minimum of four float values; 

max3,min3: calculates maximum/minimum of three float values; 
returns answer in integer form 

my_gamma (gamma. c)— puts a gamma corrected color ramp into the color map 
name_conv — converts input latitude and longitude to file name 
open_2D_terrain_wind — opens window used to draw 2D terrain map 
open_3D_terrain_wind — opens window used to draw 3D terrain map 
open_bi!lboard_wind - opens window used for displaying opening billboard 
open_dial_help_wind — opens window used for displaying dial box 
open_performance_wind -- opens window used for displaying polygon count data 
open_posit_wind — opens window used for displaying position data 
open_windows — calls modules required to open all windows 



- 56 - 



platform_crashed — creates crash in 3D window when platform’s altitude 

is less than the current elevation 



process_DIALO — processes Dial 0 queue entry: course change 

process_DIAL4 -- processes Dial 4 queue entry: look direction 

process_DIAL5 -- processes Dial 5 queue entry: look distance 

read_terrain_data — reads in terrain data used to draw 2D land image 

relocate_mouse — moves mouse location to within 2D window, executed 

when user selects "Change viewpoint" from popup menu 

set_timer (timer.c)— activates system clock, used for performance checks 

setwindow -- sets window and current window variable to gidc 

update_2D_position — updates position mark, course dead-reckoning vector, and 

look-direction vector in 2D window 

update_dial_data — inserts current course, speed, altitude, look-distance, 

look-direction, and look-angle into dials display 

update_elevation -- updates global elevation variable with current location’s 

ground elevation 

update_performance_data — updates polygon count display in performance data 

window 

update_posit -- updates latitude and longitude data in posit window 

Header files 

constants - definition of manifest constants 

filenames — path to CMA data, needed to establish data structure before 2D and 3D 
images are drawn 

terrain — definition of manifest constants used mainly in drawing routines 
typedef - defines enumerated types: viewpoint, octant, ptrl, ptr2, ptr3 
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APPENDIX D - CCWF MODULES AND WHO THEY ARE 

CALLED BY 



Source Code Files 



3d — main driver routine 
adjust_bounds -- draw_cell 
billboard - initialize_3d 
calc_breakpoints -- 3d 
cIear_overlays - 3d, do_menu 
colorramp -- init_graphics 
DefineMenu (mainmenu.c) -- 3d 
do menu - 3d 
draw_2D_terrain - 3d 
dravv_cell -- draw_terrain 
dravv_dials — 3d 
dra\v_ocean - draw_terrain 
dravv_skirt -- draw_cell 
draw_terrain -- 3d 
get_terrain -- draw_cell 
init_controIs — initialize_3d 
initgraphics — initialize_3d 
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init_queue — initialize_3d 
init_terrain -- initialize_3d 
init_view — initialize_3d 
initialize_3d -- 3d 
makelevell — get_terrain 
make_level2 - make_levell 
make_leve!3 — make_level2 
make_polly (draw_poly.c) -- draw_cell 
max3, min3 (maxmin.c) - draw_terrain 
my_gamma (gamma. c)- colorramp 
name_conv — get_terrain, read_terrain_data 
open_2D_terrain_wind — open_windows 
open_3D_terrain_wind — open_windows 
open_billboard_wind — open_windows 
opendialhelpwind — open_windows 
open_performance_wind — open_windows 
open_posit_wind -- open_windows 
open_windows - 3d 
platform_crashed - update_dial_data 
processDIALO -- 3d 
process_DIAL4 - 3d 
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process_DIAL5 — 3d 
read_terrain_data — 3d 
reIocate_mouse -- do_menu 
set_timer (timer.c) — draw_terrain 

setwindow — 3d, billboard, clear_overlays, platform_crashed, process_view_select, 
relocate_mouse, update_dial_data, update_posit 

updatedialdata -- 3d 

update_2D_position — 3d 

updateperformancedata — draw_cell 

update_posit -- 3d 



Header files 



constants — 3d, billboard, calc_breakpoints, clear_overlays, colorramp, do_menu, 
draw_2D_terrain, draw_dials, draw_ocean, draw_skirt, my_gamma, 
get_terrain, init_controls, init_graphics, init_view, open_2D_terrain_- 
wind, open_3D_terrain_wind, open_billboard_wind, open_dial_help_- 
wind, open_performance_wind,open_posit_wind, platform_crashed, 
process_DIALO, process_DIAL3, process_DIAL4, read_terrain_data, 
relocate_mouse, setwindow, update_2D_position, update_dial_data, 
update_elevation, update_performance_data, update_posit, 
update_position 

filenames — get_terrain, read_terrain_data 

terrain — adjust_bounds, draw_cell, draw_ocean, draw_poly, draw_terrain, 
process_view_select 

typedef -- 3d, do_menu, draw_2D_terrain, get_terrain, init_terrain, 

init_view, DefineMenu, make_levell, make_level2, make_level3, 
process_DLALO, process_DIAL4, read_terrain_data, relocate_mouse, 
update_2D_position, update_dial_data, update_posit, update_position 
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APPENDIX E - CCWF USER’S MANUAL 



The Command and Control Workstation of the Future’s (CCWF) primary fea- 
ture is to generate a three-dimensional visualization of a 60 nautical mile square area 
(cell). Using the Silicon Graphics, Inc. IRIS 4D-70GT graphics workstation the user 
is able to drive around the cell at a near real-time rate of animation. This visualiza- 
tion is displayed in the Three-Dimensional Terrain Window on the IRIS monitor (see 
Figure E.l). 
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Figure E.l CCWF Window Layout 
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1. Navigating 



In order to navigate (drive around) the three-dimensional image, the user 
manipulates the dials of the IRIS dial box. Figure E.2 is a drawing of the dial box 
which has a functional label below each dial. For example, to alter course, turn the 
bottom left dial either left or right dependent upon the desired action. The dials affect 
the platform (ship or aircraft) currently being viewed from. 

2. Use of Dials 



The dials’ functions are as follows. 

a. Course 

True direction platform is traveling. The unit of measure is degrees. 
Course is represented by a red line in the Two-Dimensional Terrain Window (see 
Figure E.l). The length of the red line is equal to the distance the viewer’s platform 
travels in six minutes at current speed. 

b. Speed 

The rate at which the platform is moving. The unit of measure is nauti- 
cal miles per hour (knots). Maximum speed for a ship is 35 knots. Maximum speed 
for an aircraft is 1000 knots. 

c. Altitude 

The vertical distance between the platform and sea level. The unit of 
measure is yards. Altitude for a ship is a constant ten yards. Maximum altitude for 
an aircraft is 5000 yards. 
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Figure E.2 Dial and Button Help Window 
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d. Look Direction 



The true direction the viewer is looking. Look direction is independent 
of course. For example, if the ship is traveling due North and the viewer is looking at 
an object off his port beam, then Course will be 000 and Look Direction is 270. The 
unit of measure is degrees. Look Direction is represented by a black line in the Two- 
Dimensional Terrain Window. 

e. Look Distance 

The length of the black line in the Two-Dimensional Terrain Window. 
By manipulating both Look Direction and Look Distance the user can determine the 
bearing and range to an object of interest in the 2-D window. 

The IRIS dial box is displayed in the Dial and Button Help Window (see Figure 
E.l). In addition to each dial’s functional label, the current value is displayed inside 
the dial. Also displayed in this window is the current altitude above ground. Altitude 
above ground is the vertical distance, in yards, between the user’s platform and the 
surface of the earth directly below. If this distance becomes less than or equal to 
zero, then the platform will crash. To recover from a crash, increase altitude until alti- 
tude above ground is greater than zero. 

3. Use of Buttons 

There are two buttons on the IRIS button box that affect the CCWF. By 
pressing the top left button, the grid lines are turned on or off. By pressing the bottom 
left button, the look direction is locked onto the course. When this lock is in effect, 
the Look Direction dial is disabled. To re-enable the Look Direction dial and return to 
previous Look Direction press the bottom left button again. 
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4. Position Display 



Above the Dial and Button Help Window, is the Position Window. The lati- 
tude and longitude are displayed for the platform’s current position (see Figure E.3). 



LATITUDE: 31 21 30.00 North 
LONGITUDE: 131 10 30.00 East 



Figure E.3 Position Window 

5. Two-Dimensional Display 

Above the Position Window, is the Two-Dimensional Terrain Window. 
This image represents the entire cell. The land region is color-coded relative to ele- 
vation. Blue represents water. Dark green shades represent lower elevations. Yel- 
low shades are middle elevations. Red shades are higher elevations. Also shown in 
this window is a small red circle indicating the platform’s current position. Notice 
that as the platform moves, the small red circle moves accordingly. This feature 
allows the viewer to know his relative location within the cell at all times. 

The 2-D window is the only window which may be moved and/or resized. 
To do this, position the mouse cursor (red arrow) on the top title bar of the 2-D Ter- 
rain Window. Press and hold down the right mouse button (menu button). A menu 
similar to Figure E.4 is displayed. While still holding the menu button down move the 



- 65 - 



mouse cursor (move mouse) to the selection (Move or Resize) desired. Releasing 
the menu button causes selection of the desired menu item. 




Figure E.4 Max System Menu 

a. Moving 2-D Window 

If MOVE is selected, as the mouse is moved, a red outline of the 2-D 
window will move around the screen. When the outline is in the desired location, 
press and release the menu button. The 2-D Terrain Window will now be redrawn in 
the new location. 

b. Resizing 2-D Window 

If RESIZE is selected, as the mouse is moved, a small red box will 
move around the screen. When the upper left-hand comer of the box is in the desired 
location, press and hold down the left mouse button, now drag the lower right-hand 
comer of the box to the desired window size by moving the mouse. When desired 
size is reached, release the mouse button. 

6. Performance Data Display 

Above the Two-Dimensional Terrain Window, is the Performance Data 
Window (see Figure E.5). The value displayed in this window is a count of the num- 
ber of polygons being drawn to create the three-dimensional image. The polygons 
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being drawn are of two types: single triangles when drawing coastal terrain or dou- 

ble triangles, forming a square, when drawing inland terrain. 



Polygons being drawn = 

5000 



Figure E.5 Performance Data Window 



7. CCWF Menu Features 



To access the CCWF menu system, move the cursor to the interior of any 
window. Press and hold down the menu button. A menu similar to Figure E.6 
appears. The arrows indicate that each item, except "Quit," has a sub-menu associat- 
ed with it. To select a sub-menu, slide the mouse either left or right and the sub-menu 



Main Menu 



Platform Select 



Visibility Range 



Change Viewpoint 



Quit 



Figure E.6 Main Menu 
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will appear. The features available through sub-menus are as follows. 

a. Platform Select 

Allows selection of a platform from a sub-menu similar to Figure E.7. If 
"Ship" is selected (by releasing menu button when desired item is highlighted), alti- 
tude is set to ten yards and speed is limited to less than or equal to 35 knots. Selec- 
tion of "Aircraft" (default) allows for maximum speed of 1000 knots and maximum alti- 
tude of 5000 yards. 

Choose platform 

Ship 

Aircraft 

Figure E.7 Platform Select Sub-Menu 

b. Visibility Range 

Provides a choice of visibilities to select from (see Figure E.8). 
"Unlimited" visibility is the default. 



Select Visibility 
Unlimited 
15 miles 
10 miles 

5 miles 

3 miles 



Figure E.8 Visibility Sub-Menu 
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c. Change Viewpoint 



Allows the user to change the position from which he is currently look- 
ing at the three-dimensional image. By selecting the "Select new viewpoint with left 
mouse" option (see Figure E.9), the mouse cursor is automatically relocated to the 
Two-Dimensional Terrain Window. 



In 2D window: 

Select new viewpoint with left mouse 

Return to original view with middle mouse 

Figure E.9 View Change Sub-Menu 

At this point, position the mouse cursor within the 2-D window where 
the new viewpoint is desired. Once positioned, press and release the left mouse but- 
ton. Notice, the 3-D image is now being drawn from the new position. Also notice, 
the old position is marked by a small yellow circle. The yellow circle will continue to 
move in accordance with the course and speed which was in effect when the view- 
point was changed. Viewpoint may be changed as many times as desired by follow- 
ing the above procedure. When ready to return to the original viewpoint, marked by 
the yellow circle, press and release the middle mouse button. 

d. Quit 

Selection of this menu option causes an exit to the program and return 
to the operating system prompt. 



- 69 - 



8. Conclusion 



Through the use of a logical arrangement of controls and menu driven feature 
selection, a new user will be able to master the CCWF with only a short period of 
familiarization. 
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